Side note: should we export it publicly? Which styled should devs use when e.g. creating a custom slot for the Data Grid?

They could use the one from @mui/material/styles, no? IIANM, the need to de-isolate material/styles is more for internal use.
We could also expose this one and ask them to use it but it might be difficult to effectively communicate this to the users. Wdyt?

Would it make more sense to switch from @mui/system to use styled from @mui/material/styles for now?

I recall that the use of @mui/system is to support Joy in the future but since the core team is focusing on v6, we could revisit and provide a better solution in the future.

I am going to work on bundling the grid without MaterialUI this quarter though. Which implies we remove any @mui/material import from the core of the grid's codebase.

Would it make more sense to switch from @mui/system to use styled from @mui/material/styles for now?

Thanks for pitching in @siriwatknp

I would agree with @romgrk and possibly avoid reverting to an import from @mui/material. IMO, this workaround could be a nice compromise for the time being.

Or do you see a problem with this other than this duplicated hardcoded import?

Using system styled() for GridFooterCellRoot means it's incompatible because we explicitly declare the type as sx?: MaterialTheme.

I think this should be fixed by my suggestion in internals/styled:

createStyled<Theme>({ themeId: MATERIAL_THEME_ID });

I'm also not sure how we should evolve these styles that rely on material theme. Maybe we should define a minimal default grid theme with the styles we need from material? And then we document which theme fields need to be re-defined for other design systems?

This sounds like a good approach, I would even recommend introducing CSS vars for these tokens that reads from the theme if the value exists, or fallback to some default value. That way people don’t need to define theme, they can just add CSS vars instead.

+1 for creating DataGrid CSS variables. It can be a plain object for type safety, basically to remove accessing the JS theme. Then in the, GridRootStyles declare the values using theme values from Material UI:

// dataGridCssVars.ts
// the structure below is just an example.
export const vars = {
  typography: {
    caption: {
      fontSize: '--DataGrid-typography-caption-fontSize',
      …
    }
  }
}

// GridAggregationHeader
fontSize: `var(${vars.typography.caption.fontSize}, 12px)`, // the fallback is optional

// GridRootStyles.ts
const gridStyle: CSSInterpolation = {
  [vars.typography.caption.fontSize]: t.typography.caption.fontSize,
  ...
}

Any thoughts on adding those properties on the system theme object instead?

One issue I have with CSS variables is that it's going to be a lot of boilerplate to redefine all the theme variables we need. And once we have released publically a set of CSS variables, it gets harder to add new ones because it could be a breaking change if that new variable is not defined by users, whereas the theme object covers basically every theming/styling use-case.

If we go with CSS variables, I'm also unsure if/how to adapt patterns like these ones:

• padding: theme.spacing(0.5)
• [theme.breakpoints.up('sm')]: { ...

And once we have released publically a set of CSS variables, it gets harder to add new ones because it could be a breaking change if that new variable is not defined by users

In the case of adding new variables, would we not provide a default in the Data Grid, and then users only need to define it if they wish to override the value? That should prevent breaking changes unless I'm misunderstanding.

Any thoughts on adding those properties on the system theme object instead?

What does this mean in practice? We extend the system theme by adding the properties we need, and then each consumer is responsible for providing a compatible theme object, correct?

In the case of adding new variables, would we not provide a default in the Data Grid, and then users only need to define it if they wish to override the value?

Yes in theory, in practice I feel like there could be cases where we can't find a good default.

What does this mean in practice? We extend the system theme by adding the properties we need, and then each consumer is responsible for providing a compatible theme object, correct?

Yes, that would be the idea. The theme object is more structured and already has typings and everything needed for theming.

If we go to CSS variables, we'd need to replace pretty much all of these cases with them (unless we only use CSS variables for the cases where the system theme object doesn't match the material theme, but mixing both paradigms sounds bad).

Yes, that would be the idea. The theme object is more structured and already has typings and everything needed for theming.

True, that is a valid approach and a practical one.

If we go to CSS variables, we'd need to replace pretty much all of these cases with them (unless we only use CSS variables for the cases where the system theme object doesn't match the material theme, but mixing both paradigms sounds bad).

Moving CSS will take more effort. I think it will involve a design engineer to come up with a minimal set of variables that will be used across the data grid in an efficient way (might include a redesign).

But I think it's a long term way because it does not involve JS theme anymore, it's just CSS and anyone can override theme (theming the data grid) with plain CSS.

The Theme should be the Material UI Theme + other properties that data grid wants to extend.

All the @ts-ignore will be removed by my suggestion https://github.com/mui/mui-x/pull/10498/files#r1778208301